A Domain-Specific Language for Incremental and Modular 
Design of Large-Scale Verifiably-Safe Flow Networks 

(Preliminary Report) 



We define a domain-specific language (DSL) to inductively assemble ^ow networks from small networks 
or modules to produce arbitrarily large ones, with interchangeable functionally-equivalent parts. Our 
small networks or modules are "small" only as the building blocks in this inductive definition (there 
is no limit on their size). Associated with our DSL is a type theory, a system of formal annotations 
to express desirable properties of flow networks together with rules that enforce them as invariants 
across their interfaces, i.e., the rules guarantee the properties are preserved as we build larger networks 
from smaller ones. A prerequisite for a type theory is a formal semantics, i.e., a rigorous definition of 
the entities that qualify as feasible flows through the networks, possibly restricted to satisfy additional 
efficiency or safety requirements. This can be carried out in one of two ways, as a denotational semantics 
or as an operational (or reduction) semantics; we choose the first in preference to the second, partly to 
avoid exponential-growth rewriting in the operational approach. We set up a typing system and prove its 
soundness for our DSL. 

1 Introduction and Motivation 

Flow Networks. Most large-scale systems can be viewed as assemblies of subsystems, or gadgets, each 
of which produces, consumes, or regulates a flow of some sort. In a computer network, a discrete flow 
of messages (packets) is produced by servers {e.g., streaming sources), regulated by network devices 
{e.g., routers and shapers), and consumed by clients {e.g., stream players). In a road network, the flow 
constitutes vehicles which enter and exit at edge exchanges, and which are regulated by speed limits 
on road segments, and by traffic lights at forks and intersections. In electric grids, a continuous flow 
of energy (electric cuiTcnt flow) is produced by power sources, regulated by transformers, transported 
by transmission lines, and consumed by power sinks. In a sensor network, a flow of measurements is 
produced by sensors, regulated by filters and repeaters, and consumed by sinks and aggregators. In a 
computing grid or cloud, a flow of resources {e.g., CPU cycles) is produced by physical clusters of hosts, 
regulated by schedulers, resource managers, and hypervisors, and consumed by applications. 

In each of the above systems, a "network" is assembled from smaller building blocks, which them- 
selves could be smaller, inductively assembled networks or alternately, they could be individual modules. 
Thus, what we call flow networks are inductively defined as assemblies of small networks or modules. 
The operation of a flow network is characterized by a set of variables and a set of constraints thereof, 
reflecting basic, assumed, or inferred properties or rules governing how the network operates, and what 
constitutes safe operation. Basic rules (variables and constraints) are inherently defined, and are typi- 
cally specified by a domain expert for individual modules. Assumed rules are speculatively specified 
for outsourced or yet-to-be fleshed out networks, which constitute holes in a larger network. Holes in a 
network specification allow the design or analysis of a system to proceed based only on promised func- 
tionality of missing modules or networks to be plugged in later. Inferred rules are those that could be 
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derived through repeated composition and analysis of networks. Such derivations may be exact, or may 
underscore conservative approximations (e.g., upper or lower bounds on variables or expressions). 

Basic or inferred rules - underscoring constraints on the operation of a flow network - could be 
the result of analysis using any one of a set of diverse theories or calculi. For instance, in a streaming 
network application, the size of a maximum burst of packets produced by a server over a window of 
time may be bounded using analysis that relies on real-time scheduling theory, whereas the maximum 
burst of packets emitted by a sequence of networking elements (e.g., multicast routers and shapers) over 
a (possibly different) window of time may be bounded using analysis that relies on network calculus Q. 
Clearly, when a larger flow network consisting of streaming servers as well as network elements - not to 
mention holes - is assembled, neither of these underlying calculi on its own could be used to perform the 
requisite network-wide analysis to derive the rules at the boundaries of the larger flow network. Rather, 
the properties at the boundaries of the constituent (smaller) networks of servers and networking elements 
constitute a domain-specific language (of maximum burst size over time, in this case), the semantics of 
which can be used to derive the rules at the boundaries of the larger flow network. 

Several approaches to system design, modeling and analysis have been proposed in recent years, 
overlapping with our notion of flow networks. Apart from the differences in the technical details - at the 
level of formalisms and mathematics that are brought to bear - our approach distinguishes itself from 
the others by incorporating from its inception three inter-related features/goals: (a) the ability to pursue 
system design and analysis without having to wait for missing (or broken) components/modules to be 
inserted (or replaced), (b) the ability to abstract away details through the retention of only the salient 
variables and constraints at network interfaces as we transition from smaller to larger networks, and (c) 
the ability to leverage diverse, unrelated theories to derive properties of modules and small networks, as 
long as such networks share a common formal language at their interfaces - a formal Domain-Specific 
Language (DSL) that enables assembly and analysis that is agnostic to the underlying theory used to 
derive such properties. 

Examples of DSL Use Cases. Before delving into the precise definitions and formal arguments of 
our DSL, we provide brief descriptions of how flow networks could be leveraged for two application do- 
mains - namely resource allocation and arbitration subject to Service Level Agreements (SLAs) for video 
streaming in a cloud computing setting, and emerging safety-critical CPS and smart grid applications. 

The generality of our DSL is such that it can be applied to problems in settings that are not im- 
mediately apparent as flow network settings. For example, consider a single, physical or virtual host 
(processor). One may view such a host / as the source of a supply flow of compute cycles, offered in 
constant increments c,- every period Similarily, a process or application j executing on such a host 
can be viewed as a demand flow of compute cycles, requested periodically with some characteristics - 
e.g., subject to a maximum consumption of wj cycles per period tj. In this setting, multiple supply flows 
(e.g. a set of processors in a multicore/cluster setting), each represented by an individual supply (c,-,f,) 
flow, can be regulated/managed using hypervisor system software to yield a flow network that exhibits a 
more elaborate pattern of compute cycles. For instance, the resulting flow may be specified as a single 
{cm,tm) flow, where c„, cycles are supplied over the Least Common Multiple (LCM) period ?,„, or it may 
be sepcified as a set of (ck,tk) flows, each of which operating at some discrete period t^ drawn from the 
lattice of LCM periods defined by the individual periods. Similarily, multiple demand flows (e.g. a set 
of services offered within a single virtual machine), each represented by an individual demand (wj,tj) 
flow, can be multiplexed to yield more elaborate consumption patterns of the resulting workload. Finally, 
a supply flow may be matched up to a set of demand flows through the use of a scheduler. Clearly, for 
a flow network of compute cycle producers, consumers, and schedulers to operate safely, specific con- 
straints (rules) must be satisfied. For instance, matching up supply and demand flows adhere to a "supply 
meets demand" condition, or to some other SLA, such as "periods of overload cannot exceed 100 msecs" 
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or "no more than 5 missed periodic allocations in any 1-minute window of time". 

Not only is our DSL useful in modeling the supply of, demand for, and consumption (through a 
scheduler) of compute cycles, but also in a very similar manner they can be used readily to model the 
supply of, demand for, and consumption (through resource management protocols) of other computing 
resources such as network bandwidth, storage capacities, etc. 

In the above setting, the flow networks describing the supply, demand, or scheduling of computing 
and networking resources can be made as small as desired to render their whole-system analysis tractable, 
or as large as desired to produce more precise system-wide typings. For instance, readers familiar with 
the vast literature on real-time scheduling (e.g., ll2Tll23ll24i ) will immediately recognize that most of the 
results in that literature can be viewed as deriving fairly tight bounds on specific processor schedulers 
such as EDF, RMS, Pinwheel, among others schedulers. Similarily, readers familiar with QoS provi- 
sioning using network calculus, traffic envelopes, fluid network models will recognize that most of the 
results obtained through these models are applicable for specific protocols such as AIMD, weighted-fair 
queuing, among other schedulers (e.g., |[7l l20ll26l ). 

Modeling and analysis of the supply of (and demand for) computing and networking resources is 
particulai^ly valuable in the context of cloud and grid resource management (e.g., |[Tl[ll[l4l[l7l|271). In 
such a setting, a cloud operator may use a DSL to specify the topological configuration of computing 
and networking resources, the layer of system software used to virtualize these resources, as well as a 
particular mapping of client workloads to virtualized resources. Compiling such a DSL-sepecification is 
akin to verifying the safety of the system. Moreover, making changes to these DSL specifications enables 
the operator (or a mechanized agent thereof) to explore whether an alternative arrangement of resources 
or an alternative mapping of client workloads is more efficient |[T6l . 

As another example of the broad applicablity of our DSL, consider yet another application domain 
- that of smart electric grids. In this domain, a module would be a grid "cell", such as a power plant, a 
residential or commercial building, a power transmission line, a transformer, or a power storage facility 
(batteries), etc. Each cell has a capacity to produce and consume power over time (energy flow). For 
example, a house with solar panels may be contributing a positive flow to the grid or a negative flow de- 
pending on the balance between solar panel supply and house demand. Operational or safety constraints 
on cells and interconnections of cells define relationships that may be the subject of exact whole-system 
analysis on the small scale, or approximate compositional analysis on the large scale. The simplest of 
cells is perhaps a transmission line, which may be modeled by input and output voltages v,v, and Vout, a 
maximum allowable drop in voltage 5,., a resistance R which is a function of the medium and transmis- 
sion distance, a current rating /, and a power rating P. Ignoring delays, one can describe such a cell by a 
set of constraints: e.g. , Vout - Vm -R*I (the voltage at the output is the difference between the input volt- 
age and the voltage drop due to resistance), Vout *I <P (the power drain cannot exceed a maximum rated 
wattage), and 7? * / < 5,, (the drop in voltage must be less than what is allowed). Similarly, modules for 
other types of cells may be specified (or left unspecified as holes) and arrangements of such modules may 
be used to model large-scale smart grids, allowing designers to explore "what if" scenarios, e.g., under 
what conditions would a hole in the grid cause a safety violation? or what are the most efficient settings 
(e.g., power generation and routing decisions) in terms of power loss due to inefficient ti"ansmission? The 
introduction of "smart" computational processes in the grid (e.g., feedback-based power management) 
and the expected diversity of technologies to be plugged into the grid make the consideration of such 
questions quite critical. 

A Type Theory and Formal Semantics of Flow Networks. Associated with our DSL is a type theory, 
a system of formal annotations to express desirable properties of flow networks together with rules that 
enforce them as invariants across their interfaces, i.e., the rules guarantee the properties are preserved as 
we build larger networks from smaller ones. 
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A prerequisite for a type theory is a formal semantics - a rigorous definition of the entities that 
qualify as feasible flows through the networks, possibly restricted to satisfy additional efficiency or 
safety requirements. This can be carried out in one of two ways, as a denotational semantics or as 
an operational (or reduction) semantics. In the first approach, a feasible flow through the network is 
denoted by a function, and the semantics of the network is the set of all such functions. In the second 
approach, the network is uniquely rewritten to another network in normal form (appropriately defined), 
and the semantics of the network is its normal form or directly extracted from it. Though the two 
can be shown to be equivalent (in a sense that can be made precise), whenever we need to invoke a 
network's semantics, we rely on the denotational definition in order to avoid complexity issues related to 
the operational definition. Some of these complexity issues are already evident from the form of network 
specifications we can write in our DSL. 

As we alluded before, a distinctive feature of our DSL is the presence of holes in network specifi- 
cations, together with constructs of the form: let X = in M , which informally says "network A4 may 
be safely placed in the occurrences of hole X in network M". What "safely" means will later depend 
on the invariant properties that typings are formulated to enforce. There are other useful hole-binders 
besides let-in, which we denote try-in, mix-ln, and letrec-ln. An informal explanation of what these 
hole-binders mean is in Remark[6]and Example |7J 

Rewriting a specification in order to eliminate all occurrences of holes and hole-binders is a costly 
process, generally resulting in an exponential growth in the size of the expression denoting the specifica- 
tion, which poses particular challenges in the definition of an operational semantics. We set up a typing 
system and prove its soundness for our DSL without having to explicitly carry out such exponential- 
growth rewriting. 

Our DSL provides two other primitive constructs, one of the form (A^i || M.2) and another of the 
form bind (7V^, {a,b)). The former juxtaposes two networks Aii and Ai2 in parallel, and the latter binds 
the output arc a of a network M to its input arc b. With these primitive or core constructors, we can 
define many others as derived constructors and according to need. 

Paper Overview and Context. The remainder of this paper is organized as follows. Section|2]is devoted 
to preliminary definitions. Section [3] introduces the syntax of our DSL and lays out several conditions 
for the well-formedness of network specifications written in it. We only include the let-in constructor, 
delaying the full treatment of try-In, mlx-in, ietrec-ln, to subsequent reports. 

The formal semantics of flow networks are introduced in Section |4] and a con^esponding type theory 
is presented in Section [S] The type theory is syntax-directed, and therefore modular, as it infers or 
assigns typings to objects in a stepwise inside-out manner. If the order in which typings are inferred for 
the constituent parts does not matter, we additionally say that the theory is fully compositional. We add 
the qualifier "fully" to distinguish our notion of compositionality from similar, but different, notions in 
other areas of computer science^] We only include an examination of modular typing inference in this 
paper, leaving its (more elaborate) fully-compositional version to a follow-up report. 

The balance of this paper expands on the fundamentals laid out in the first four sections: Sections |6] 
to [To] mostly deal with issues of typing inference, whether for the basic semantics of flow networks 
(introduced in Section |4ll or their relativized semantics, whereby flows are feasible if they additionally 
satisfy appropriately defined objective functions (introduced in Section |9l). 

Acknowledgment. The work reported in this paper is a small fraction of a collective effort involving 
several people, under the umbrella of the iBench Initiative at Boston University. The reader is invited 
to visit the website https : //sites . google . com/ site/ibenchbu/ for a list of participants. 



Adding to the imprecision of the word, "compositional" in the literature is sometimes used in the more restrictive sense of 
"modular" in our sense. 
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former participants, and other research activities. The DSL presented in this paper, with its formal 
semantics and type system, is in fact a specialized and simpler version of a DSL we introduced earlier in 
our work for NetSketch, an integrated environment for the modeling, design and analysis of large-scale 
safety-critical systems with interchangeable parts |l5l|6l|25l. In addition to its DSL, NetSketch has two 
other components currently under development: an automated verifier (AV), and a user interface (UI) 
that combines the DSL and the AV and adds appropriate tools for convenient interactive operation. 

2 Preliminary Definitions 

A small network A is of the form A - (N,A) where N is a set of nodes and A a set of directed arcs. 
Capacities on arcs are determined by a lower-bound L : A and an upper-bound U : A satisfying 
the conditions L(a) ^ U (a) for every a e A. We write M and for the sets of all reals and all non-negative 
reals, respectively. We identify the two ends of an arc a e A by writing head{a) and tail{a), with the 
understanding that flow moves from tail{a) to head{a). The set A of arcs is the disjoint union (denoted 
"i+i") of three sets: the set A# of internal arcs, the set Ain of input arcs, and the set Aout of output arcs: 

A# i±) Ain ty Aout where 
{ a e A I head{a) e N and tail{a) e N } 
{ a e A I head{a) e N and tail{a) ^ N } 
{a e A I head{a) ^ N and tail{a) e N} 

The tail of an input arc, and the head of an output arc, are not attached to any node. We do not assume A 
is connected as a directed graph - a sensible assumption in studies of network flows, whenever there is 
only one input arc (or "source node") and one output arc (or "sink node"). We assume N * 0, i.e., there 
is at least one node in N, without which there would be no input and no output arc, and nothing to say. 

A flow / in ,A is a function that assigns a non-negative real to every a e A. Formally, a flow is a 
function / : A ^ M"*" which, if feasible, satisfies "flow conservation" and "capacity constraints" (below). 

We call a bounded interval [r,r'] of reals, possibly negative, a type, and we call a typing a function 
T that assigns a type to every subset of input and output arcs. Formally, T is of the following formQ 

T : ^(AinUAout) ^ MxM 

where ^{ ) is the power-set operator, i.e., i^(Ain u Aout) = {A |A c Ajn u Aout}- As a function, T is not 
totally arbitrary and satisfies certain conditions, discussed in Section \5\ which qualify it as a network 
typing. Instead of writing T{A) - {r,r'), where A £ Ain uAout, we write T{A) - [r,r']. We do not disallow 
the possibility that r> r' which will be an empty type satisfied by no flow. 

Informally, a typing T imposes restrictions on a flow / relative to every A £ Ajn u Aout which, if 
satisfied, will guarantee that / is feasible. Specifically, if T{A) - [r,r'], then T requires that the part of 
/ entering through the arcs in A n Ain minus the part of / exiting through the arcs in A n Aout rnust be 
within the interval [r,r']. 

Remark 1. Let A - (N,A) be a small network. We may want to identify some nodes as producers and 
some others as consumers. In the presence of lower-bound and upper-bound functions L and U , we do 
not need to do this explicitly. For example, if n is a node that produces an amount r e M^, we introduce 

^Our notion of a "typing" as an assignment of types to the members of a powerset is different from a similarly-named 
notion in the study of type systems for programming languages. In the latter, a typing refers to a derivable "typing judgment" 
consisting of a program expression M, a type assigned to M, and a type environment with a type for every free variable in M. 
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instead a new input arc a entering n with L{a) - U {a) - r. Similariy, if n' is a node that consumes an 
amount / e M*, we introduce a new output arc a' exiting n' with L(a') = U {a') - r' . The resulting network 
A' is equivalent to A, in that any feasible flow in A' induces a feasible flow in A, and vice-versa. □ 

Flow Conservation, Capacity Constraints, Type Satisfaction. Though obvious, we precisely state 
fundamental concepts underlying our entire examination and introduce some of our notational conven- 
tions, in Definitions 121 m m and [5] 

Definition 2 {Flow Conservation). If A is a subset of aixs in A and / a flow in A, we write Y,f{A) 
to denote the sum of the flows assigned to all the arcs in A: E/(A) = E{/('3!) |a e A}. By convention, 
X!0 = 0. If A = {a\ , . . . ,ap} is the set of all arcs entering node n, and B - {b\,. . . is the set of all arcs 
exiting node n, then conservation of flow at n is expressed by the linear equation: 

(1) E/(^) - Y.m 

There is one such equation for every node « e N. □ 
Definition 3 {Capacity Constraints). A flow / satisfies the capacity constraints at aix a e A if: 

(2) L{a) ^ f{a) ^ U{a) 

There are two such inequalities for every arc a e A. □ 
Definition 4 {Feasible Flows). A flow / i?, feasible iff two conditions: 

• for every node n e N, the equation in ([T|l is satisfied, 

• for every arc a e A, the two inequalities in Q are satisfied, 

following standard definitions of network flows. □ 

Definition 5 {Type Satisfaction). Let T ■ ^(Ajn u Aout) M x R be a typing for the small network A. 
We say the flow / satisfies T if, for every A e ,^(Ain u Aout) with T{A) - [r, /], it is the case: 

(3) ^/(AnAin) - ^/(AnAout) 

We often denote a typing T for A by simply writing A-T. □ 



3 DSL for Incremental and Modular Design of Flow Networks (Untyped) 

The definition of small networks in Section |2] was less general than our full definition of networks, but 
it had the advantage of being more directly comparable with standard graph-theoretic definitions. Our 
networks in general involve what we call "holes". A hole X is a pair (Ain, Aout) where Ajn and Aout are 
disjoint finite sets of input and output arcs. A hole X is a place holder where networks can be inserted, 
provided the matching-dimensions condition (in Section [l!2l ) is satisfied. 

We use a BNF definition to generate formal expressions, each being a formal description of a net- 
work. Such a formal expression may involve subexpressions of the form: \et X-A4 '\n M , which 
informally says "A4 may be safely placed in the occuiTcnces of hole X in M". What "safely" means 
depends on the invariant properties that typings are formulated to enforce. In such an expression, we call 
the X to the left of "=" a binding occun^ence, and we call all the X's in J\f bound occuiTcnces. 

If ^ = (N,A) is a small network where A = A# tu Ain ty Aout, let in(^) = Ajn, out(^) = Aout, and 
#{A) = A#. Similai-ly, if X = (Ain, Aout) is a hole, let in(X) = Ain, out(X) = Aout, and #(X) = 0. We 
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assume the arc names of small networks and holes are all pairwise disjoint, i.e., every small network and 
every hole has its own private set of arc names. 

The formal expressions generated by our BNF are built up from: the set of names for small networks 
and the set of names for holes, using the constructors || , let-in, and bind: 



A,B,C e SmallNetworks 

X,Y,Z 6 HOLEN AMES 

M,J\f,V e Networks 



A 
X 

M\\M 

\etX^M\nM 

bind {M,{a,b)) 



small network name 

hole name 

parallel connection 

let-binding of hole X 

bind head{a) to tail{b), where 

(a,Z7) eout(7V)xin(7V) 



where in{M) and out(AA) are the input and output arcs of M. In the full report |[T9l . we formally define 
in(AA) and out(AA), as well as the set #(A/^) of internal arcs of M, by structural induction. 

We say a flow network J\f is closed if every hole X in is bound. We say J\f is totally closed if it 
is closed and in(A/^) = out(AA) = 0, i.e.,M has no input arcs and no output arcs. 



3.1 Derived Constructors 

From the three primitive constructors introduced above: || , let-in, and bind, we can define several other 
constructors. Below, we present four of these derived constructors precisely, and mention several others 
in Remark |6] Our four derived constructors are used as in the following expressions, where M , Mu and 
M j, are network specifications and Q is set of arc pairs: 

bind(AA,0) conn(M,AA2,0) Ni®N2 letXe {A4i,...,A^„} in A/" 

The second above depends on the first, the third on the second, and the fourth is independent of the three 
preceding it. Let be a network specification. We write 6 <^\.\ out(AA) x in(AA) to denote a partial 
one-one map from out(AA) to in(AA). We may write the entries in Q explicitly, as in: 

B = {{ai,bi),...,{akM)} 

where ai, . . . e out(A/') and Zji,. . . e in (A/"). 

Our first derived constructor is a generalization of bind and uses the same name. In this generaliza- 
tion of bind the second argument is now 6 as above rather than a single pair {a,b) e out(A^) x in(AA). 
The expression bind (A/, 6) can be expanded as follows: 

bind(AA,0) ^ bind (bind (••• bind (AA,(«,,Z.,))-,(a2,ZP2)),(ai,^i)) 

where we first connect the head of au, to the tail of bk and lastly connect the head of to the tail oib\. A 
little proof shows that the order in which we connect arc heads to arc tails does not matter as far as our 
formal semantics and typing theory is concerned. 

Our second derived constructor, called COnn (for "connect"), uses the preceding generalization of 
bind together with the constructor || . LetA/^i and A/'2 be network specifications, and 6 <^i.\ out(A/'i) xin(A/'2). 
We expand the expression COnn(A/'i, A/2,0) as follows: 



conn(A/'i,A/'2,0) 



bind((AAi \\N2),B) 
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In words, COnn connects some of the output arcs in A^i with as many input arcs in M2- 

Our third derived constructor is a special case of the preceding COnn. Unless otherwise stated, we 
will assume there is a fixed ordering of the input arcs and another fixed ordering of the output arcs of a 
network. Let A^i be a network specification where the number m ^ 1 of output arcs is exactly the number 
of input arcs in another network specification A/2, say: 

out(M) = {«!,•••,«/«} and m{Af2) ^ {bi, . . . ,b„,} 

where the entries in out(AAi ) and in in(A/2) are listed, from left to right, in their assumed ordering. Let 

0= {{ai,bi),...,{a,„,b,r,)} = out{Afi) x in{Af2) 

i.e., the first output arc of Mi is connected to the first input arc Zji of ^2, the second output arc a2 of 
J\f\ to the second input arc b2 of A/2, etc. Our derived constructor (A/i ©A/2) can be expanded as follows: 

(AAi®Ar2) => conn(A/'i,Ar2,0) 

which implies that iii(7V^i ®A/'2) = in(A/'i) and out(A/'i ® A/'2) = out(A/'2). As expected, ® is associa- 
tive as far as our formal semantics and typing theory are concerned, i.e., the semantics and typings for 
TVi ® (A/2 ©A/a) and (A/i ffiA/'2) ffiA/3 are the same. 

A fourth derived constructor generalizes let-in and is expanded into several nested let-bindings: 

{\etXe{Mu...,Mn} InA/") => {\etXi^Mi In (■•• (letX„ = 7W„ in (ATj || ••• ■■■)) 

where Xi,...,X„ are fresh hole names and Mj is M with X,- substituted for X, for every 1 ^ / ^ n. Infor- 
mally, this constructor says that every one of the networks {M\,. . . , A^„} can be "safely" placed in the 
occurrences of X in M. 

Remark 6. Other derived constructors can be defined according to need in applications. We sketch a 
few. An obvious generalization of © cascades the same network A/^ some « > 1 times, for which we write 
®i^M A condition for well-formedness is that A/''s input and output dimensions must be equal. 

Another derived constructor is Merge(A^i , A/2, A/3) which connects all the output arcs of M\ and M2 
to all the input arcs of A/s. For well-formedness, this requires the output dimensions of M\ and A/2 to add 
up to the input dimension of A/3. And similarly for a derived constructor of the form Fork(AAi,A/'2,A/3) 
which connects all the output arcs of J\f\ to all the input arcs of J\f2 and Mj,. 

While all of the preceding derived constructors can be expanded using our primitive constructors, 
not every constructor we may devise can be so expanded. For example, a constructor of the form 

tryZe {Mu---Mn} inAA 

which we can take to mean that at least one Mi can be "safely" placed in all the occurrences of X in J\f, 
cannot be expanded using our primitives and the way we define their semantics in Section |4l Another 
constructor also requiring a more developed examination is of the form 

mlxXe {M\,...,M„} In A/" 

which we can take to mean that every combination (or mixture) of one or more Mj can be selected at the 
same time and "safely" placed in the occurrences of X in J\f, generally placing different M.i in different 
occurrences. The constructors try-In and mix-ln are examined in a follow-up report. An informal 
understanding of how they differ from the constructor let-in can be gleaned from Example |7J 
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Another useful constructor introduces recursively defined components with (unbounded) repeated 
patterns. In its simplest form, it can be written as: 

\etrecX^M[X] \nJ\f[X] 

where we write A^[X] to indicate that X occurs free in Ai, and similarly in M. Informally, this con- 
struction con^esponds to placing an open-ended network of the form A4[A^[A^ [■•■]]] in the occurrences 
of X in M. A well-formedness condition here is that the input and output dimensions of M. must match 
those of X . We leave for future examination the semantics and typing of letrec-itl, which are still more 
involved than those of try-in and mix-in. □ 

3.2 Well-Formed Network Specifications 

In the full report |[T9ll . we spell out 3 conditions, not enforced by the BNF definition at the beginning of 
Section [3j which guarantee what we call the well-formedness of network specifications. We call them: 

• the matching-dimensions condition, 

• the unique arc-naming condition, 

• the one binding-occurrence condition. 

These three conditions are automatically satisfied by small networks. Although they could be easily 
incorporated into our inductive definition, more than BNF style, they would obscure the relatively simple 
structure of our network specifications. 

We only briefly explain what the second condition specifies: To avoid ambiguities in the formal 
semantics of SectionUl we need to enforce in the specification of a network J\f that no arc name refers to 
two different arcs. This in turn requires that we distinguish the arcs of the different copies of the same 
hole X. Thus, if we use k^2 copies of X, we rename their arcs so that each copy has its own set of 
arcs. We write ^X, . . . ,*^X to refer to these k copies of X. For further details on the unique arc-naming 
condition, and full explanation of the two other conditions, the reader is referred to |[T9l . 

Example 7. We illustrate several of the notions introduced so far. We use one hole X, and 4 small 
networks: F ("fork"), ("merge"). A, and B. These will be used again in later examples. We do not 
assign lower-bound and upper-bound capacities to the arcs of F, A, and B - the arcs of holes are 
never assigned capacities - because they play no role before our typing theory is introduced. Graphic 
representations of F, and X are shown in Figure [TJ and of A and B in Figure |2] A possible network 
specification M with two bound occurrences of X may read as follows: 

N ^ ietx ^{A,B} in conn( F, conn( 'x, conn( ^X, l\/l,03),02),0i) 

where 0i = {(c2, ^^i), (c3, '^2)}, B2 = ('64,^62)}, and 63 = {{^eT,,d\_),{\^,d2)}. We wrote M 

above using some of the derived constructors introduced in Section [3?T] Note that: 

• all the output arcs {02,03} of F are connected to all the input arcs {^e\, ^ez} of 'X, 

• all the output arcs {^03, '04} of ^X are connected to all the input arcs {'^ei,^e2} of ^X, 

• all the output arcs {^^3,^04} of ^X are connected to all the input arcs {di,d2} of 
Hence, according to Section IXTl we can write more simply: 



M = letX e{A,B} in (Fe'Xe^XeM) 
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with now m{M) = {ci} and out(A/') = {d^}- The specification Af says that A or B can be selected for 
insertion wherever hole X occurs. Though we do not define the reduction of let-in-bindings formally, M 
can be viewed as representing two different network configurations: 

J\fi = FeUe^^eM and AA2 = Fe^Be^BeM 

We can say nothing here about properties, such as safety, being satisfied or violated by these two config- 
urations. The semantics of our let-in constructor later will be equivalent to requiring that both configu- 
rations be "safe" to use. By contrast, the constructor try-in mentioned in Remark |6] requires only A^i or 
A/2, but not necessarily both, to be safe, and the constructor mlx-ln additionally requires: 

AA3 = FeUe^iSeM and J\f4 = Fe^Be^AeM 

to be safe. Safe substitution into holes according to mlx-in implies safe substitution according to let-in, 
which in turn implies safe substitution according to try-In. □ 




Figure 1: Small network F (on the left), small network M (in the middle), and hole X (on the right), in Example]?] 




Figure 2: Small networks A (on the left) and B (on the right) in Example|7l 



4 Formal Semantics of Flow Networks 

The preceding section explained what we need to write to specify a network formally. Let M be such a 
network specification. By well-formedness, every small network A appearing in M has its own separate 
set of arc names, and every bound occurence 'X of a hole X also has its own separate set of arc names, 
where 1 is a renaming index. (Renaming indeces are defined in Section [l!2l ) With every small network 
A, we associate two sets of functions, its full semantics lA} and its lO-semantics {{A)). Let Ajn = in(^), 
Aout = out(,A), and A# = #(^). The sets {A} and {{A)) are defined thus: 

Ml - {f- Ain ty Aout ty A# ^ I / is a feasible flow in ,A } 

{{A)) - {f ■ Ain i+i Aout ^ I / can be extended to a feasible flow /' in ^ } 
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Let X be a hole, with m{X) - Ain and out(X) = Aout- The. full semantics [Xj and the lO-semantics {{X)) 
are the same set of functions: 

IX j = {{X)) c {/ : Ain i±) Aout ^ I / is a bounded function } 

This definition of pC} - {{X)) is ambiguous: In contrast to the uniquely defined full semantics and 10- 
semantics of a small network A, there are infinitely many pC} - {{X)) for the same X, but exactly one 
(possibly fx} - {{X)) - 0) will satisfy the requirement in clause 4 below. 

Starting from the full semantics of small networks and holes, we define by induction the full seman- 
tics \N'\ of a network specification J\f in general. In a similar way, we can define the lO-semantics ((AA)) 
of M by induction, starting from the lO-semantics of small networks and holes. For conciseness, we 
define \M\ separately first, and then define ((A/")) from \J\f\ . We need a few preliminary notions. Let M. 
be a network specification. By our convention of listing all input arcs first, all output arcs second, and all 
internal arcs third, let: 

in{M) ^ {ai,...,ak}, out(A^) = and ^M) ^ {aku+i,...,aku+„,}. 

If / 6 IM\ with f{ai ) = ri , . . . ,f{at+e+m) = ^-yt+f+m, we may represent / by the sequence {n,..., n+e+m)- 
We may therefore represent: 

• [/]in(>f) by the sequence {n,---, ru), 

' [/]out(7Vi) by the sequence (r^+i , . . . , rt+e), and 

• [f]#(M) by the sequence {n+M , . . .,rk+(+m), 

where [/]out(A^)' ^'^'^ [/]#(x)' restrictions of / to the subsets in{M), out(A^), and 

#(A^), of its domain. Let M be another network specification and g e {M}. We define / || g as follows: 

(/ II g) = [/]in(A^) ■ [.?]in(Ar) ' [/]out(A1) ' [.?]out(Ar) ' [/]#(A4) ' [.?]#(A^) 

where "•" is sequence concatenation. The operation " || " on flows is associative, but not commutative, 
just as the related constructor " || " on network specifications. We define the full semantics |A^]] for every 
subexpression M. of M, by induction on the structure of the specification M: 

1. If7W = Athen[A^l = [^l. 

2. If 7W = 'X,then ='[Xl. 

3. If = {Vi II V2), then {Mj = { (/i || A) | /i e fPij and /2 e }• 

4. If = (let X^VinV), then IMj = provided two conditions^] 

(a) dim(Z) ^ dim(P), 

(b) m - {[g]Jg^m} where A ^m{V)uout{V). 

5. If M ^ bind {V,{a,b)), then IMj = {/ | / e |Pl and /(a) = /(Z.) }. 

"'"dim(X) « dim(P)" means the number of input arcs and their ordering (or input dimension) and the number of output 
arcs and their ordering (or output dimension) of X match those of V, up to arc renaming (or dimension renaming). Similarly, 
"1^1 ~ {[sIaIs I^I }" ni'^ans for every / : in{X) tti out{X) ^ R+, it holds that / e [X] iff there is g e fPj such that / ~ [g]^, 
where [g]^ is the restriction of g to the subset A of its domain. 
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All of TVA is a special case of a subexpression of M, so that a the semantics of M is simply [[AA| . Note, 
in clause 2, that all bound occurrences 'X of the same hole X are assigned the same semantics up to 
renaming of arc names. We can now define the lO-semantics of J\f as follows: 

where A - in(AA) uout(AA) and [/]^ is the restriction of / to A. 

Remark 8. For every small network A appearing in a network specification J\f, the lower-bound and 
upper-bound functions, L_4 and Uj,, are already defined. The lower-bound and upper-bound for all of M, 
denoted Lj^ and L^v", are then assembled from those for all the small networks. However, we do not need 
to explicitly define and Ujsf at every step of the inductive definition of J\f. 

In clause 4, the lower-bound and upper-bound capacities on an input/output arc a of the hole X are 
determined by those on the corresponding arc, say a' , in V. Specifically, Lx{a) - L-p{a') and Ux{a) - 
U-p{a'). In clause 5, the lower-bound and upper-bound are implicitly set. Specifically, consider output 
arc a and input arc b in V, with L-p and U-p already defined on a and b.lf A4 = bind {V, {a,b)), then: 

Lm{<^) - max {L-p (a), L-p (b)} 
UM{a) = min {Up (a), Up (b)} 

which are implied by the requirement that f{a) = f{b). In A^, arc a is now internal and arc b is altogether 
omitted. On all the arcs other than a, Lj^ and Um are identical to L-p and Up, respectively. □ 
Remark 9. We can define rewrite rules on network specifications in order to reduce each into an equiv- 
alent finite set of network specifications in normal form, a normal form being free of try-in bindings. 
We can do this so that the formal semantics of network specifications are an invariant of this rewriting. 
This establishes the soundness of the operational semantics (represented by the rewrite rules) of our DSL 
relative to the formal semantics defined above. We avoid formulating and presenting such rewriting rules 
in this report, for reasons alluded to in the Introduction and again in the last section. □ 

Flow Conservation, Capacity Constraints, Type Satisfaction (Continued). The fundamental con- 
cepts stated in relation to small networks A in Definitions |2l [21 and|4j are extended to arbitrary network 
specifications M. These are stated as "properties" (not "definitions") because they apply to IM} (not to 
Af), and [AA] is built up inductively from { [^| | A occurs in Af}. 

Property 10 (Flow Conservation - Continued). The nodes of M are all the nodes in the small networks 
occurring in J\f, because our DSL in Section\3\does not introduce new nodes beyond those in the small 
networks. Hence, {M} satisfies flow conservation because, for every small network A in J\f, every f e [^J 
satisfies flow conservation at every node, i.e., the equation in ([7]) in Definition^ 

Property 11 (Capacity Constraints - Continued). The arcs introduced by our DSL, beyond the arcs in 
the small networks, are the input/output arcs of the holes. Lower-bound and upper-bound capacities on 
the latter arcs are set in order not to conflict with those already deflned on the input/output arcs of small 
networks. Hence, \N"\ satisfles the capacity constraints because, for every small network A in J\f, every 
f e l^Aj satisfles the capacity constraints on every arc, i.e., the inequalities in (|2]) in Deflnition\3\ 

However, stressing the obvious, even if [^| t for every small network A in M, it may still be that 
M is unsafe to use, i.e., it may still be that there is no feasible flow in J\f because \N'\ - 0. We use the 
type system (Section |7]) to reject unsafe network specifications M. 

Definition 12 {Type Satisfaction - Continued). Let A/^ be a network, with Ajn = in(AA), Aout = out(A/^), 
and A# = #(AA). A typing T for M, also denoted {J\f : T), is a function 

T : ^(AinUAout) ^KxM 
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which may, or may not, be satisfied by / e {{Af)) or by / e |{AA|. We say / e {{Af)) or / e {Af} satisfies T 
iff, for every A c Ajn u Aout with T{A) - [r, r'], it is the case that: 

(4) r ^ ^/(AnAin) - ^ /(An Aout) ^ / 

The inequalities in extend those in Q in Definition |5] to network specifications in general. □ 

5 Typings Are Polytopes 

Let M he a. network specification, and let Ain = in(AA) and Aout = out(AA). Let T be a typing for M that 
assigns an interval [r,r'] to A £ Ajn u Aout- Let |Ain| + |Aout| = ni, for some m ^ 0. As usual, there is a fixed 
ordering on the aixs in Ajn and again on the aixs in Aout- With no loss of generality, suppose: 

Ai^AnAin^{ai,...,ak} and A2 = A n Aout = W+i , . . . ,a£}, 

where £ ^ m. Instead of writing r(A) = [r,r'], we may write: 

r(A): ai+--- + ak-ak+i flf : [r,r'] 

where the inserted polarities, + or -, indicate whether the arcs are input or output, respectively. A flow 
through the arcs {ai, . . . ,ak} contributes a positive quantity, and through the arcs {a^+i ,...,a(} ^negative 
quantity, and these two quantities together should add up to a value within the interval [r, r']. 

A typing T for Ain u Aout induces a polytope (or bounded polyhedron), which we call Poly(r), in 
the Euclidean hyperspace M"'. We think of the m arcs in Ain u Aout as the m dimensions of the space M'". 
Poly(r) is the non-empty intersection of at most 2- (2'" - 1) halfspaces, because there are (2'" - 1) non- 
empty subsets in (Ain u Aout). The interval [r, r'], which T assigns to such a subset A = {a\ , . . . ,a^} as 
above, induces two linear inequalities in the variables {cJi, . . ■,af}, denoted T^{A) and T^{A): 

(5) T^{A): £?! H vaf^-ajf^i ctf/^r and T<^(A): vuf^-aj^^i cig ^ r' 

and, therefore, two halfspaces Half(rj(A)) and Half(r^(A)): 

(6) Half(rj(A)) = {reM'" I r satisfies rj(A)} and Half(r<:(A)) = {reM'" | r satisfies r^(A) } 
We can therefore define Poly(r) formally as follows: 



Poly(r) = n{Half(r,(A)) n Half(r^(A)) 



Generally, many of the inequalities induced by the typing T will be redundant, and the induced Poly(r) 
will be defined by far fewer than 2 • (2™ - 1 ) halfspaces. 

5.1 Uniqueness and Redundancy in Typings 

We can view a network typing T as a syntactic expression, with its semantics Poly(r) being a polytope 
in Euclidean hyperspace. As in other situations connecting syntax and semantics, there are generally 
distinct typings T and T' such that Poly(r) = Poly(r'). This is an obvious consequence of the fact that 
the same polytope can be defined by many different equivalent sets of linear inequalities, which is the 
source of some complications when we combine two typings to produce a new one. 



0?tAc AinUAoutl 
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To achieve uniqueness of typings, as well as some efficiency of manipulating them, we may try an 
approach that eliminates redundant inequalities in the collection: 

(7) {r,(A)|0^Ae^(AinUAout)} u { r,(A) | * A e ^(Ai^ uAo^t) } 

where T^{A) and r^(A) are as in ^ above. There are standard procedures which determine whether 
a finite set of inequalities are linearly independent and, if they are not, select an equivalent subset of 
linearly independent inequalities. Some of these issues are taken up in the full report |[T9l . 

If Ml ■ Ti and M2 ■ T2 are typings for networks Mi and M2 with matching input and output di- 
mensions, we write Ti = T2 whenever Poly(ri) rj Poly(r2), in which case we say that Ti and T2 are 
equivalent^lf Ml ^ M2, then Ti = T2 whenever Poly(ri) = Poly(r2). 

Definition 13 (Tight Typings). Let M he a. network specification, with Ajn = in(M) and Aout = out{M), 
and T : =^(Ain u Aout) M X M a typing for M. T is a tight typing if for every typing T' such that T = T' 
and for every A £ Ain u Aout, the interval T{A) is contained in the interval T'{A), i.e.,T{A) £T'{A). □ 

Proposition 14 (Every Typing Is Equivalent to a Tight Typing). There is an algorithm Tight{ ) which, 
given a typing (M -T) as input, always terminates and returns an equivalent tight typing {M ■ Tight{T)). 

5.2 Valid Typings and Principal Typings 

Let A/" be a network, Ajn = \n{M) and Aout = out(A/'). A typing M -T is valid iff it is sound: 
(soundness) Every /o : Ain u Aout ^ satisfying T can be extended to a feasible flow / e fM} . 
We say the typing M -T for M is a. principal typing if it is both sound and complete: 
(completeness) Every feasible flow / e {M} satisfies T. 

More succintly, using the lO-semantics {{M)) instead of the full semantics {M} , the typing M -T is valid 
iff Poly(r) c {{M}, and it is principal iff Poly(r) = {{M}. 

A useful notion in type theories is subtyping. If Ti is a subtype of T2, in symbols Ti <-T2, this means 
that any object of type Ti can be safely used in a context where an object of type T2 is expected: 

(subtyping) Ti <: iff Poly(r2) c Poly(ri). 

Our subtyping relation is contravariant w.r.t. the subset relation, i.e., the supertype T2 is more restrictive 
as a set of flows than the subtype Ti . 

Proposition 15 (Principal Typings Are Subtypes of Valid Typings). If{M ■ Ti) is a principal typing, and 
(M ■T2) a valid typing for the same M, then Ti <: T2. 

Any two principal typings Ti and T2 of the same network are not necessarily identical, but they 
always denote the same polytope, as formally stated in the next proposition. 

Proposition 16 (Principal Typings Are Equivalent). If (M ■ Ti) and {M ■ T2) are two principal typings 
for the same network specification M, then Ti = T2. Moreover, if Ti and T2 are tight, then Ti = T2. 



"Poly(ri) fs Poly(r2)" means that Poly(ri) and Poly(72) are the same up to renaming their dimensions, i.e., up to 
renaming the input and output arcs in Afi and AA. 
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6 Inferring Typings for Small Networks 



Theorem 17 (Existence of Principal Typings). Let Abe a small network. We can effectively compute a 
principal and uniformly tight typing T for A. 

Example 18. Consider again the two small networks A and B from Example |7] We assign capacities to 
their arcs and compute their respective principal typings. The sets of arcs in A and B are, respectively: 
A = {^1, . . . and B = {Z^i , . . . All the lower-bounds and most of the upper-bounds are trivial, 

i.e., they do not restrict flow. Specifically, the lower-bound capacity on every arc is 0, and the upper- 
bound capacity on every arc is a "very large number", unless indicated otherwise in Figure [3] by the 
numbers in rectangular boxes, namely: 



[/(as) = 5, U{as)^lO, [/(an) = 15, 

U{b5)^3, U{be)^2, [/(Zp9)=2, [/(^iq) = 10, 

U{bu)-S, U{bi3)-S, [/(Z7i5) = 10, U{bie)-7, 



non-trivial upper-bounds in A, 
non-trivial upper-bounds in B, 
non-trivial upper-bounds in B. 



We compute the principal typings T_a of A and of B, by assigning a bounded interval to every subset 
of {ai } and {bi,b2,b^,b4}, respectively. This is a total of 15 intervals for each, ignoring the 

empty set to which we assign the empty interval 0. We use the construction in the proof (omitted in this 
paper, included in the full report |[T9l ) of Theorem [l7] to compute 7^ and Tq. 

Tyi assignments : 



ai : [0,15] 





[0,25] 




-a3:[-15,0] 




-^4: [-25,0] 



ai+a2-[0,30] 



ai -c[3 : [-10, 10] ai -a4 : [-25, 15] 



aj-ai,: [-15,25] 

ai+a2-a3 ■ [0,25] 
ai + a2- as - a4 ■ [0, 0] 



-£23 -a4 ■■ [-30,0] 



«2 -^^4 ■ [-10, 10] 

fl] +^2 -^^4 ■ [0, 15] ai -^3 -0:4 : [-25,0] 0:2 -fl^3 -fl^4 • [-15,0] 



Tq assignments : 



^i:[0,15] 



^1+^2: [0,30] 



bi- by. [-10, 12] ^1-^4: [-25, 15] 



Z.2-^3:[-15,25] 

Z.i+Z.2-^3:[0,25] 
bi+b2-b3-b4-[0,0] 



-b3-b4-[-30,0] 



b2-b4- [-12,10] 

bi+b2-b4-[0,l5] Z^i-^3-^4:[-25,0] ^2 -^3 -^4 ^ [-15,0] 





[0,25] 




-^3: [-15,0] 




-Z.4:[-25,0] 



The types in rectangular boxes are those of [TUjj^^ and [Telj^ which are equivalent, and those of [TUj^^ 
and [Tb]^^,^ which are also equivalent. Thus, [r^];^ e [Tb]^^ and [TaIoui = [^elout- Nevertheless, T_a i Tb, 
the difference being in the (underlined) types assigned to some subsets mixing input and output arcs: 

• [-10, 10] assigned by Tj( to {ai,ai,} t [-10, 12] assigned by to the con^esponding {b\,bj,}, 

• [-10, 10] assigned by T_a to {02,^^4} * [-12, 10] assigned by Tq to the corresponding {Z?2,^4}. 

In this example, Tb <■ Tj^^ because Poly(r4) c Poly(rg). The converse does not hold. As a result, there 
are feasible flows in B which are not feasible flows in A. □ 
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7 A Typing System 

We set up a formal system for assigning typings to network specifications. The process of inferring 
typings, based on this system, is deferred to Section [H We need several preliminary definitions. 



7.1 Operations on Typings 

Let (A^i : Ti) and (^2 : T2) be two typings for two networks A^i and A/2. The four arc sets: in(A/'i), 
out(AAi), in(A/'2), and out(A/'2), are pairwise disjoint. By our inductive definition in Section[3l in(A/'i) u 
in(A/'2) is the set of input arcs, and 001(^^1 ) u 001(^2) the set of output arcs, for the network specification 
(M II ^2). We define the typing (Ti || T2) for the specification (A^i || A/2) as follows: 



{Ti\\T2){A) 



TiiA) 



ifA cin(7^i)uout(AAi), 
if A c in( A/2 ) u out (A/2 ) , 



ri(Ai)®r2(A2) if A =Ai UA2 where 

A 1 c in(AAi ) u out(A/'i ) and A2 £ in(A/'2) u out(A/'2) . 



where the operation "®" on intervals is defined as follows: [r\ ,r2]9[r[, r'2] - [ri +r\,r2 + r'2]. 

Lemma 19. If (Afi ■■ Ti) and {M2 '■ T2) are principal typings, respectively valid typings, then so is the 
typing {{Afi || A/2) ■ {Ty \\ T2)) principal, respectively valid. 

Let (A/" : r) be a typing with {a,b)e out (A/") x in (A/"), with dimin(AA) = ( ) anddimout(AA) = 

(a^+i , . . . ,a„,), so that b - a,- and a - aj for some 1 ^ / ^ ^ and ^+ 1 ^ j ^ m. In the full report [ 19] we explain 
how to define a typing we denote b'm6{T,{a,b)) from the given typing T for the network specification 
bind (A/", (a, Zj)) satisfying the equation: Poly(bind(r, (a,^;))) = Poly(r) n Poly(a = Zj) where 



Poly(a -b) - { (ri , . . . , r„,) e R'" \ rj - rj } where b - aj and a - aj with I ^i ^ £ < j ^ 



m. 



Lemma 20. If {M ■■ T) is a principal (respectively, valid) typing and {a,b) e in{Af) xout{J\f), then 
(bind (A/", {a,b)) ■.b\r\6{T,{a,b))) is a principal ( respectively, valid) typing. 
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7.2 Typing Rules 



The system is in Figured where we follow standai^d conventions in formulating the rules. We call F a 
typing environment, which is a finite set of typing assumptions for holes, each of the form (X : T). If 
(X : r) is a typing assumption, with in(X) = Ajn and out(X) = Aout, then T ■ ^(Ajn u Aout) -^^ M x R. 

If a typing T is derived for a network specification M according to the rules in Figure |4j it will be 
the result of deriving an assertion (or judgment) of the form "F i- : T". If M is closed, then this final 
typing judgment will be of the form "^- M ■ T" where all typing assumptions have been discharged. 



Hole 
Small 

Par 

Bind 

Let 



(X : r) 6 r 

r H 'X:'T 

Ft- A-T 
r H AAi : Ti 



/ ^ 1 is the smallest available renaming index 
r is a typing for small network A 



r H AA2 : ^2 



r^{Afi\\M2)--{Ti\\T2) 
Fh bind (7V,(fl,/7)):bind(r,(fl,^)) 

ThM-.Ti Fu{(X:r2)} h A/":r 

Fh (letX = A^ \nAf):T 



{a,b) € out(A/') X in{J\f) 



Figure 4: Typing Rules for Flow Networks. 

The operations (Tj || T2) and bind(r, (a,/?)) are defined in Section |7?T] A derivation according to the rules is 
stopped from the moment a judgment F 1- AA : T is reached such that Poly(r) = 0, at which point Af is rejected as 
"unsafe". 

Theorem 21 (Existence of Principal Typings). Let Af be a closed network specification and T a typing 
for J\f derived according to the rules in Figure^ i.e., the judgment "\- Af :T" is derivable according 
to the rules. If the typing of every small network A in Af is principal (resp., valid) for A, then T is a 
principal (resp., valid) typing for Af. 



8 Inferring Typings for Flow Networks in General 

The main difficulty in typing inference is in relation to let-bindings. Consider a specification Af of the 
form (let X= in "P ). Let Ajn = in(X) and Aout = out(X). Suppose X occurs n^l times in V, so that its 
input/output arcs are renamed in each of the n occurrences according to: ^(Ajn u Aout) , ■■■ , "(^in u Aout)- 
A typing for X and for its occurrences 'X in V can be given concretely or symbolically. If concretely, 
then these typings are functions of the form: 

Tx ■■ ^(Ain u Aout) ^ M X M and % ■■ ^i%n u 'Aout) M X M 

for every l^i^n. According to the typing rule HOLE in FigurelH a vahd typing for Af requires that: Tx ~ 
^Tx Ri ••• Ri "Tx - If symbolically, then for every B c Ajn u Aout, the interval Tx{B) is written as [a:^,^^] where 
the two ends xg and ys are yet to be determined, and similarly for 'Tx{B) and every B c Ain u Aout- We 
can infer a typing for Af in one of two ways, which produce the same end result but whose organizations 
are very different: 

(sequential) First infer a principal typing Jvj for A4, then use k copies ^T_m "Tj^ to infer a principal 
typing Tp for V, which is also a principal typing T// for Af. 
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(parallel) Infer principal typings T^vi for M. and Tp for V, separately. T-p is parametrized by the typings 
'Tx written symbolically. A typing for M is obtained by setting lower-end and upper-end parameters 
in 'Tx to corresponding lower-end and upper-end values in T^vf. 

Both approaches are modular, in that both are syntax-directed according to the inductive definition of 
M. However, the parallel approach has the advantage of being independent of the order in which the 
inference proceeds (i.e., it does not matter whether is inferred before or after, or simultaneously with, 
Tp). We therefore qualify the parallel approach as being additionally fully compositional, in contrast 
to the sequential approach which is not. Moreover, the latter requires that the whole specification J\f 
be known before typing inference can start, justifying the additional qualification of being a whole- 
specification analysis. The sequential approach is simpler to define and is presented in full in |[T9l . We 
delay the examination of the parallel/fully-compositional approach to a follow-up report. 

9 Semantics of Flow Networks Relative to Objective Functions 

Let A/" be a network, with Ajn = in{M), Aout = out(7V^), and A# = #{Af). We write Aout,# to denote 
Aoutt9A#, the set of all arcs in M excluding the input arcs. An objective fimction selects a subset of 
feasible flows that minimize (or maximize) some quantity. We list two possible objective functions, 
among several others, commonly considered in "traffic engineering" (see for example). 

Minimize Hop Routing (HR) A minimum hop route is a route with minimal number of links. 

Given a feasible flow / e IM\, we define the quantity hr(/) = EcieAou,#/(^)- Given two feasible 
flows /i ,/2 € |AA1^ we write f\ <™' f2 iff two conditions: 

• [/i]a,„ = [/2]a.„> and 

• HR(/i)<HR(/2). 

Note that we compare fi and fi using only if they assign the same values to the input arcs, 
which implies in particular that fi and carry equal flows across M. It can be shown that hr(/i ) < 
hr(/2) holds iff fi is non-zero on fewer arcs in Aout,# than /2, i.e., 

|{aeAout,#|/i(a) *0}| < |{a e Aout,# | /2(a) * 0}| 

We write /i ^"'^ to mean /i /2 or hr(/i ) = hr(/2). 

Minimize Arc Utilization (AU) The utilization of an arc a is defined as u{a) - f{a)/U (a). 

Given a feasible flow / e [A/"], we define the quantity Au(/) = EaeA„u,#"(^)- Given two feasible 
flows /i ,/2 e [A/"]], we write /i iff two conditions: 

• [/i]a.„ = [/2]a,^ and 

• AU(/i)<AU(/2). 

It can be shown that Au(/i ) < Au(/2) holds iff: 

^{l/?7(a) |aeAout,#and/i(a) *0} < ^{ l/?7(a) | a e Aout.# and /2(a) 0} 

Minimizing arc utilization corresponds to computing "shortest paths" from inputs to outputs using 
l/U {a) as the metric on every arc in Aout,#- We write fi f2 to mean fi f2 or Au(/i ) = Au(/2). 

For the rest of this section, consider a fixed objective a e {hr, AU, . . . }. We relativize the formal semantics 
of flow networks as presented in Section IH To be correct, our relativized semantics requires that the 
objective a be an "additive aggregate function". 
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Definition 22 {Additive Aggregate Functions). Let TV be a network and consider its set [AA] of feasible 
flows. A function a ■ [AAJ is an additive aggregate if «(/) is of the form EaeAou,# ^(/)^) for some 
function : [A/"! x Aout,# M+. □ 

The particular objective functions HR and AU considered above ai^e additive aggregate. For HR, the 
con^esponding function 6 is the simplest and defined by d{f,a) = f{a). And for AU, the corresponding 
function 6 is defined by d{f,a) - f{a)/U (a). All the objective functions considered in ||3l are additive 
aggregate. 

The full semantics of a flow network M relative to objective a, denoted [AA|a]], will be a set of 
triples each of the form {f,B,r) where: 

• / e IM}, i.e., / is a feasible flow in Af, 

• Bcin(Ar)uout(AA), 

• r^a{f), 

such that, for every feasible flow g e {Afj, if [f]^ - [g]g then a{g) ^ r. The information provided by 
the parameters B and r allows us to determine [[AA| aj compositionally, i.e., in clause 5 in the definition 
of [AA|a]] below: We can define the semantics of a network A4 relative to a from the semantics of 
its immediate constituent parts relative to a. Informally, if {f,B,r) e lM\a}, then among all feasible 
flows that agree on B, flow / minimizes «(/). We include the parameter r = «(/) in the triple to avoid 
re-computing a from scratch at every step of the induction, by having to sum over all the arcs of M. 
Based on the preceding, starting with small networks A, we define the full semantics of A relative to the 
objective a as follows: 

lA\aj ^ {{f,B,r)\f€lAj, Bcin{A)uout{A), r^a{f), 

and for every g e {Aj, if = [g]^ then «(/) ^ a{g) } 

The lO-semantics ((^| a)) of the small network A relative to the objective a is: 

{{A\a)) ^{{[f]^,B,r)\{f,B,r)elAM} 

where A = in(^) uout(.4). As in Section |4l the full semantics [X | aj and the lO-semantics {{X | a)) of a 
hole X relative to the objective a are the same. Let Ain = in(X) and Aout = out(X), so that: 

lX\a} = {{X\a)) c |/:AinUAout^M+, BgAinUAout, ^eM^, and/isbounded} 

Again, as in Section |4j |X | o;| = {{X \a)) is not uniquely defined. Whether this assigned semantics of X 
will work depends on whether the condition in clause 4 below is satisfied. 

We define {Ai \ a} for every subexpression Ai of M, by induction on the structure of the specifica- 
tion M. The five clauses here are identical to those in SectionlH except for the a-relativization. The only 
non-trivial clause is the 5th and last; Proposition |23] establishes the correctness of this definition: 

1. lfM^A,thenlM\aj^lA\al 

2. If 7W = X, then [A^ | «! = %X \ aj. 

3. lfM^{Vi II P2), then 

|A4|al = {(/i II /2,BiuB2,n +?-2) I (/i,Bi,ri) e [Pi |al and (/2,S2,r2) e [P2|«l} 
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4. If = (letX=P inP'), then lM\aj = a], provided two conditions 

(a) dim(X) ^ dim(P), 

(b) |X|al ^{{[g]^,C,r)\{g,C,r) elV\aj} where A = iii(P) uout(P). 

5. If M^h\ndiV,{a,b)), then 

[A^lal = {(/,B,r)| {f,Bu{a,b},r)elV\al f{a)^f{b), 
and for every {g,Bu{a,b},s) e [["Plal 
if g{a)^g{b) and = U]^ then 5} 

We define {{M\a)) from [AA| a]: ((AA| a)) = { ([/]^,B,r) | (/,B,r) e [A/"! «! } where A = in(AA) uout(A/'). 

Proposition 23 (Correctness of Flow-Network Semantics, Relativized). Let M be a network specification 
and let a be an additive aggregate objective. For every f -Am uAour uA# M^, every B<^Ain ^Aout, and 
every r e M^, it is the case that: 

(/,S,r)6|AA|al ijf f^lM\andr^a{f)and 

for every g e {M}, if [f]^ = a(g) ^ r. 

/« vvord^, /or every B c A;„ uAout, among all feasible flows in M that agree on B, we include in IM \ a] 
those that are a-optimal and exclude from \h[ \ a\ those that are not. 

10 A Relativized Typing System 

Let a be an additive aggregate objective, e.g., one of those mentioned in Section |9l Assume a is fixed 
and the same throughout this section. Let be a closed network specification. According to Section |7J 
if the judgment "h J\f ■ T" is derivable using the rules in Figure|4]and T is a valid typing, then Poly(r) is 
a set of feasible lO-flows in J\f, i.e., Poly(r) c {{J\f)). And if T is principal, then in fact Poly(r) = {{J\f)). 

In this section, judgments are of the form "1- : (r,<I>)" and derived using the rules in Figured We 
call (r,0) a relativized typing, where T is a typing as before and <I> is an auxiliary function depending 
on the objective a. If T is a valid (resp. principal) typing for M, then once more Poly(r) c {{M)) (resp. 
Poly(r) = ((A/"))), but now the auxiliary <I> is used to select members of Poly(r) that minimize a. 

If this is going to work at all, O should not inspect the whole of M. Instead, should be defined 
inductively from the relativized typings for only the immediate constituent parts of 7V^. We first explain 
what the auxiliary O tries to achieve, and then explain how it can be defined inductively. The objective 
a is already defined on IM}, as in Section |9l We now define it on ((A/")). For every / e {{M)), let: 

«(/) = min { «(/') I /' e [A^l and / extends /}. 

As before, let Ain = in{M) and Aout = out{M). Let T be a valid typing for M, so that Poly(r) g ((AT)). 
For economy of writing, let T - Poly(r). Relative to this T, we define the function <I>y as follows: 

: ^(AinUAout)^=?^(^xM+) 

^riB) . { (/,r) I / 6 ^, r = «(/), and for every geT,if [f]„ = [g]„, then r^a{g)} 
^Review footnote[3]for the meaning of "fa". 
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where B e =^^(Ain u Aout)- In words, ^j-i^) selects / provided, among all members of ^ c {{M)) that 
agree with / on B, / is a-optimal - and also appends to / its a-value r for book-keeping purposes. 
Whenever the context makes it clear, we omit the subscript 'T" from "Oj." and simply write "O". 

The trick here is to define the auxiliary function <I> for M from the corresponding auxiliary functions 
for the immediate constituent parts of M. The only non-trivial step follows the 5th and last clause in the 
definition of [A/"] aj in Section |9l 

Definition 24 {Valid and Principal Relativized Typings). Let (r,0) be a relativized typing for M, where 
in(AA) = Ain and out(AA) = Aout- We define Poly*(r,0) as a set of triples: 

Poly*(r,<I>) = {(/,B,r)|BcAi„uAou,and(/,r)ea>(B)} 

We call this function "Poly*()" because of its close association with "Poly()", as it is easy to see that: 

P0\y*{T,<^) = {(/,B,r) 1/6 Poly(r),ScAi„u Aout, r =«(/), 

and for all g e Poly(r) if [f]^ = [g]^ then «(/) ^ a{g) } 

We say the relativized typing (AA : (r,<I>)) is valid iff Poly*(r,<I>) £ {{J\f\a)), and we say it is principal 
iff Poly'(r,<I)) = ((AA|a)). □ 

A case of particular interest is when B - Ain. Suppose (/,Ain,r) e Poly*(r,<I>). This means that, 
among all feasible flows g inM agreeing with / on Ain, / is a-optimal with «(/) = r. 

10.1 Operations on Relativized Typings 

There are two different operations on relativized typings depending on how they are obtained from previ- 
ously defined relativized typings. These two operations are "(Ti ,<!>[ ) || (72,^2)" "bind((r,0), (a,Z?))", 
whose definitions are based on clauses 3 and 5 in the inductive definition of [AA| a| in Section |9l 

Let (A/i : (ri,<I>j)) and (A/2 : (72,^2)) '^^^ relativized typings for two networks A/i and A/2- 
Recall that the the four arc sets: in(AAi), out(A/i), in(A2), and out(A/'2), are pairwise disjoint. We 
define the relativized typing (r,0) = (ri,Oj) || (72,^2) "^^e specification (A^i || A/2) as follows: 

• r = (Ti II 72), as defined at the beginning of Section ITTTl 

• for every Bi c in(A/'i) uout(A/'i) and every B2 E in(A/'2) LJ0ut(A/'2): 

a>(BiuB2) = {((/i ||/2),n+r2)|(/i,n)6<I>i(Bi)and(/2,r2)e02(B2)} 

Lemma 25. If the relativized typings (^Afi ■ (ri,<I>j)) and (A/'2 : (72,^2)) principal, resp. valid, then 
so is the relativized typing i^M\ || M2) ■ ((7i,<I>j) || (r2,<I>2)) principal, resp. valid. 

Let (P : (r,<I>)) be a relativized typing for network specification V. We define the relativized typing 
{T*,^*) = bind((r,<I>),(£?,Z7)) for the network bind {V, {a,b)) as follows: 

• T* ^b\nd(T,{a,b)), as defined in Section O 

• forevery Be (in(P)uout(P))-{a,Z?}: 

= {([/L,r) I {f,r)€^{Bu{a,b}), f{a)^f{b), and for all {g,s) ^^{Bu {a,b}) 
if g{a) = g{b) and = [g]^^ then r^s] 

Lemma 26. If the relativized typing ("P : (r,<I>)) is principal, resp. valid, then so is the relativized typing 
(bind {V,{a,b)) :bind((r,<I>),(a,Z7))) principal, resp. valid. 
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Figure 5: Relativized Typing Rules for Flow Networks. 



The operations "(ri,<l>j) || (r2,<I>2)" and "bind((r,<I>), (a,^))" are defined in Section fTO.il A derivation according 
to the rules is stopped from the moment a judgment F i- : (r,<I>) is reached such that Poly* (r,<t>) = 0, at which 
point AA is rejected as "unsafe". 

10.2 Relativized Typing Rules 

Theorem 27 (Existence of Relativized Principal Typings). Let M be a closed network specification 
and (r,<I>) a relativized typing for J\f derived according to the rules in Figure\5l i.e., the judgment 
" \- J\f (T ,f£>) " is derivable according to the rules. If the relativized typing of every small network A in 
M is principal (resp., valid) for A, then {T,(£>) is a principal (resp., valid) relativized typing for M. 

11 Related and Future Work 

Ours is not the only study that uses intervals as types and polytopes as typings. There were earlier 
attempts that heavily drew on linear algebra and polytope theory, mostly initiated by researchers who 
devised "types as abstract interpretations" - see ifTTI and references therein. However, the motivations 
for these earlier attempts were entirely different and applied to programming languages unrelated to our 
DSL. For example, polytopes were used to define "invariant safety properties", or "types" by another 
name, for ESTEREL - an imperative synchronous language for the development of reactive systems |[T5l . 

Apart from the difference in motivation with earlier works, there are also technical differences in 
the use of polytopes. Whereas earlier works consider polytopes defined by unrestricted linear constraints 
|[T2l[T5l . our polytopes are defined by linear constraints where every coefficient is +1 or -1, as implied 
by our Definitions |2j [3l HI and [S] Ours are identical to the linear constraints (but not necessarily the 
linear objective function) that arise in the network simplex method llT3l . i.e., linear programming applied 
to problems of network flows. There is still on-going research to improve network-simplex algorithms 
{e.g., |[22l ). which will undoubtedly have a bearing on the efficiency of typing inference for our DSL. 

Our polytopes-cum-typings are far more restricted than polytopes in general. Those of particular 
interest to us correspond to valid typings and principal typings. As of now, we do not have a charac- 
terization - algebraic or even syntactic on the shape of linear constraints - of polytopes that are valid 
network typings (or the more restrictive principal network typings). Such a characterization will likely 
guide and improve the process of typing inference. 

Let A/" be a network specification, with Ajn = in(AA) and Aout = out(AA). Another source of cuiTcnt 
inefficiency is that valid and principal typings for M tend to be "over-specified", as they unnecessarily 
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assign an interval-cum-type to every subset of Aj^ i+i Agut- Several examples in |fT9l illustrate this kind of 
inefficiency. This will lead us to study partial typings T ■ ^(Ain i+i Aout) M x R, which assign intervals 
to some, not necessarily all, subsets of Ajn tu Aout- Such a partial mapping T can always be extended to a 
total mapping T' ■ ^(Ain ty Aout) M x M, in which case we write T c T'. We say the partial typing T is 
valid for M if every (total) typing T' 5 T is valid for M, and we say T is minimal valid for A/" if T is valid 
for M and for every partial typing T" for M such that T" ^ T, i.e., T" assigns strictly fewer intervals 
than T, it is the case that T ^ T'. And similarly for the definitions of partial typings that are principal and 
minimal principal for J\f. 

As alluded in the Introduction and again in Remark |9j we omitted an operational semantics of our 
DSL in this paper to stay clear of complexity issues arising from the associated rewrite (or reduction) 
rules. Among other benefits, relying on a denotational semantics allowed us to harness this complexity 
by performing a static analysis, via our typing theory, without carrying out a naive hole-expansion (or 
let-in elimination). We thus traded the intuitively simpler but costlier operational semantics for the more 
compact denotational semantics. 

However, as we introduce other more complex constructs involving holes in follow-up reports (try- 
in, mix-in, and letrec-in mentioned in the Introduction and in Remark |6] of Section O this trade-off 
will diminish in importance. An operational semantics of our DSL involving these more complex hole- 
binders will bring it closer in line with various calculi involving patterns (similar- to our holes in many 
ways, different in others) and where rewriting consists in eliminating pattern-binders. See |[2ll4ll9l [T0l[T8l 
and references therein. It remains to be seen how much of the theory developed for these pattern calculi 
can be adapted to an operational semantics of our DSL. 
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